A Domain Speci c Language for Video Device Drivers : from Design to
نویسندگان
چکیده
Machine Program GAL Program IntelAbstractMachineAlphaAbstractMachineDeviceDriverX11InterpreterInterpreterWindows 95 Figure 3: Multiple implementations.6 Conclusions and Future WorkDomain speci c languages hold the promise of de-livering high payo s in terms of software reuse, au-tomatic program analysis, and software engineering.In this paper we have presented GAL, an exampleof a complete DSL for a realistic program family:video device drivers. We also demonstrated the ben-e ts of DSLs by showing how GAL raises the level ofabstraction of device driver speci cations and iden-tifying some analyses that can be performed on GALspeci cations because it is domain speci c.A further contribution of the paper is to validateour framework of application generator design byapplying it to this program family to provide animplementation of GAL. Since our implementationis based on partial evaluation, it provides a com-plete interpreter for prototyping device drivers, butstill automatically generates e cient device drivers.E ciency is demonstrated with results comparinghand-coded drivers to automatically generated de-vice drivers. Generated drivers are roughly one thirdlarger than hand-code drivers and perform equiva-lently in terms of speed. Additionally, we give mea-sures on expected reuse bene ts; GAL speci cationsare roughly a factor of 9 smaller than a driver hand-coded in C.Although our framework signi cantly reduces thedevelopment time of application generators, futurework could be done in this direction. Speci -cally, this approach would bene t from a generator-speci c reuse method that would allow interpretersand abstract machines to be constructed from reusedcomposable parts. Additionally, given the natureof DSLs, they are extended frequently to adapt tonew program requirements, and the ease of exten-sion also needs to be considered for such languagecomponents.Our implementation of the static analyses indi-cates that methods of quickly constructing staticanalyses should also be investigated (e.g., compos-able analyses). This is more important for DSLsthan GPLs, since static analyses are a major moti-vation of the approach.In this work we have presented an application ofour approach to a program family with existing fam-ily members. To further validate the approach, it isalso important to study its application to a programfamily which is not pre-existing. In this case, theabstract machine and DSL might be developed fromthe results of a domain analysis or a commonalityanalysis, such as FAST [12].References[1] B.R.T. Arnold, A. van Deursen, and M. Res.An algebraic speci cation of a language describ-ing nancial products. In M. Wirsing, editor,ICSE-17 IEEE Workshop on Formal MethodsApplication in Software Engineering, pages 6{13, April 1995.[2] J. Bentley. Programming pearls: Little lan-guages. Comm. of the ACM, pages 711{716,August 1986.[3] H.K. Berg, W.E. Boebert, W.R. Franta, andT.G. Moher. Formal Methods of Program Veri-cation and Speci cation. Prentice-Hall, Engle-Wood Cli s, NJ, 1982.[4] J. A. Bergstra and P. Klint. The ToolBus coor-dination architecture. In Ciancarini and Hankin[8], pages 75{88.[5] E. Bjarnason. Applab: a laboratory for appli-cation languages. In L. Bendix, K. N rmark,and K sterby, editors, Proceedings of the NW-PER'96 (Nordic Whorkshop on Programming Environment Research), Aalborg, number R-96-2019 in Dept. of Mathematics and ComputerScience. Aalborg University, May 1996.[6] J. Bosch and G. Hedin, editors. Proceedingsof ALEL'96 (Compiler Techniques for Appli-cation Domain Languages and Extensible Lan-guage Models), Linkoping., number LU-CS-TR:96-173 in Dept. of Computer Science. LundUniversity, April 1996.[7] Satish Chandra, Brad Richards, and James R.Larus. Teapot: Language support for writingmemory coherence protocols. In Proceedings ofof the ACM SIGPLAN'96 Conference on Pro-gramming Language Design and Implementa-tion, pages 237{248, 1996.[8] Paolo Ciancarini and Chris Hankin, editors.Coordination and models, Proceedings of therst international conference, Cesena, Italy,number 1061 in LNCS. Springer Verlag, 1996.[9] J. Graig Cleaveland. Building application gen-erators. IEEE Software, July 1988.[10] C. Consel, L. Hornof, F. Noel, J. Noy e, and E.N.Volanschi. A uniform approach for compile-time and run-time specialization. In O. Danvy,R. Gluck, and P. Thiemann, editors, PartialEvaluation, International Seminar, DagstuhlCastle, number 1110 in Lecture Notes in Com-puter Science, pages 54{72, February 1996.[11] C. Consel and F. Noel. A general approach forrun-time specialization and its application to C.In Conference Record of the 23rd Annual ACMSIGPLAN-SIGACT Symposium on PrinciplesOf Programming Languages, pages 145{156, St.Petersburg Beach, FL, USA, January 1996.[12] N.K. Gupta, L. J. Jagadeesan, E. E. Kout-so os, and D. M. Weiss. Auditdraw: Gener-ating audits the fast way. In Proceedings ofthe Third IEEE International Symposium onRequirements Engineering, pages 188{197, Jan-uary 1997.[13] N.D. Jones. An introduction to partial evalua-tion. ACM Computing Surveys, 28(3):480{503,September 1996.[14] N.D. Jones. What not to do when writingan interpreter for specialisation. In O. Danvy,R. Gluck, and P. Thiemann, editors, PartialEvaluation, International Seminar, DagstuhlCastle, number 1110 in Lecture Notes in Com-puter Science, pages 216{237, February 1996.[15] N.D. Jones, C. Gomard, and P. Sestoft. Par-tial Evaluation and Automatic Program Gen-eration. International Series in Computer Sci-ence. Prentice-Hall, EngleWood Cli s, NJ, June1993.[16] R. Kieburtz, L. McKinney, J. Bell, J. Hook,A. Kotov, J. Lewis, D. Oliva, T. Sheard,I. Smith, and L. Walton. A software engineeringexperiment in software component generation.In Proceedings of the 18th IEEE InternationalConference on Software Engineering ICSE-18,pages 542{553, 1996.[17] David Ladd and Christopher Ramming. Twoapplication languages in software production.In USENIX Symposium on Very High LevelLanguages, New Mexico, October 1994.[18] G. Necula. Proof-carrying code. In ConferenceRecord of the 24th Symposium on Principles OfProgramming Languages, pages 106{116, Paris,France, January 1997. ACM Press.[19] John K. Ousterhout. Scripting: Higher-level programming for the 21st century.White paper, Sun Labs, 1997. Avail-able at http://www.sunlabs.com/people/john.ousterhout/.[20] C. Pu, A. Black, C. Cowan, J. Walpole, andC. Consel. Microlanguages for operating systemspecialization. In wDSL'97 [24], pages 49{57.[21] Scott Thibault and Charles Consel. A frame-work for application generator design. InProceedings of the Symposium on SoftwareReusability, Boston, MA, USA, May 1997.[22] M.G.J. van den Brand, A. van Deursen,P. Klint, S. Kluesener, and E.A. van derMeulen. Industrial applications of ASF+SDF.In Albebraic Methodology and Software Method-ology (AMAST '96), volume 1101 of LNCS,pages 9{18. Springer Verlag, 1996.[23] A. van Deursen and P. Klint. Little languages:little maintenance? In wDSL'97 [24], pages109{127.[24] 1st ACM-SIGPLAN Workshop on Domain-Speci c Languages, Paris, France, January1997. Technical Report, Department of Com-puter Science, University of Illinois at Urbana-Champaign.[25] TheXFree86Project,Inc.http://www.xfree86.org/. A A Complete GAL ExampleAppendix B gives a complete listing of the GAL speci cation for several models of S3 video adaptors. Inthis appendix, we explain some of the constructs that were not included in the main text.Although the various registers of video cards are typically accessed using an addressing scheme, there issometimes a sequential procedure that must be followed to access some registers. The serial construct isused to specify this kind of procedure (see listing). The construct consists of a list of sequences of actionsthat should be performed on the ports to access the registers. Thus multiple ports may be accessed duringthe procedure, as in the example. Each sequence consists of a port, an operation (<= write, <=> read/write,=> read), and a sequence of values for writes or registers names for reads and read/writes. The actions inthe sequence are performed from the rst port to the last, from left to right in the sequence. The mode (Rread, R/W read/write, W write) to the right of the sequence indicates whether this sequence applies to readingthe registers to writing the registers or both.The serial construct in the example de nes the registers PLL1, and PLL2. In order to write values to theseregisters the construct would be executed as follows. Write 3 to misc[3..2], write the value of PLL1 toseq(0x12), write the value of PLL2 to seq(0x13), and nally, write 0, then 1, then 0 to seq(0x15)[5].The S3 speci cation also includes an example of a derived eld, which is not discussed in the paper. Thisis a eld whose value is derived from one of the standard elds. In the example, StartFIFO is a derivedeld. Its value is set whenever the graphics mode is set, and is based on the value of HTotal, the horizontalresolution. The declaration indicates this with the from clause.The clockmap is used when a card has both xed and programmable clocks such as the S3 Trio cards. Itindicates which clocks are xed and which are programmable. The example for the S3 indicates that clock0 and 1 are xed, clock 2 is not available (NA), and clock 3 is the programmable clock f3. The parametersMinPClock and MaxPClock are also related to clocks and specify the minimum and maximum values thatcan be generated by the clock (i.e. not all values of f3M, f3N1, and f3N2 are valid).Finally, the operating mode access is used to lock an unlock registers on the card.B GAL S3 Listing-List all cards/models supported by this driver.chipsets S3_911,S3_924,S3_80x,S3_928,S3_864,S3_964,S3_866,S3_868,S3_968,S3_TRIO32,S3_TRIO64;-Define ports.port svga indexed:=0x3d4;port seq indexed:=0x3c4;port misc := 0x3cc, 0x3c2;-Define registers.register Miscr:=misc;register Slock:=seq(0x8);register Offset:=svga(0x13);register ExtChipID:=svga(0x2e);register ChipID:=svga(0x30);register Memory:=svga(0x31);register State:=svga(0x36);register Lock1:=svga(0x38);register Lock2:=svga(0x39);register StartFIFOr:=svga(0x3B);register Misc1:=svga(0x3a);register Control:=svga(0x42);register Control2:=svga(0x51);register HOverflow:=svga(0x5D); register VOverflow:=svga(0x5E);register Control3:=svga(0x69);-Serial registers (see appendix A).serial beginmisc[3..2]<= (3,,-,-,-) W;seq(0x12)<=> (-,PLL1,-,-,-) R/W;seq(0x13)<=> (-,PLL2,-,-,-) R/W;seq(0x15)[5]<=(-,,0,1,0) W;end;-Define predefined fields-Horizontal resolution fields.field HTotal := HOverflow[0]#std;field HEndDisplay := HOverflow[1]#std;field HStartBlank := HOverflow[2]#std;field HStartRetrace := HOverflow[4]#std;-Vertical resolution fields.field VTotal := VOverflow[0]#std;field VEndDisplay := VOverflow[1]#std;field VStartBlank := VOverflow[2]#std;field VStartRetrace := VOverflow[4]#std;-Virtual screen fields.field LogicalWidth := Control2[5..4]#Offset scaled 8;casesfor S3_928,S3_968,S3_TRIO32,S3_TRIO64field StartAddress := Control2[1..0]#Memory[5..4]#std;for S3_80xfield StartAddress := Control2[0]#Memory[5..4]#std;for S3_864,S3_964field StartAddress := Control3[4..0]#std;for othersfield StartAddress := Memory[5..4]#std;end;-Define derived fields (see appendix A).field StartFIFO from HTotal := HOverflow[6]#StartFIFOr offset 10 scaled 8;-Special S3 flags that must be set for 256 color graphics modes.enable SVGAMode sequence is Misc1[4]<=1,Memory[3]<=1;-Define standard parameters.param TwoBankRegisters:=false;param InterlaceDivide := true;casesfor S3_911,S3_924param RamSize:=State[5] mapped (0=>1024,1=>512);for othersparam RamSize:=State[7..5] mapped (0=>4096,2=>3072,3=>8192,4=>2048,5=>5120,6=>1024,7=>512);end; -Define clocks.casesfor S3_TRIO32,S3_TRIO64param NoClocks:=4;field ClockSelect:=Miscr[3..2];param MinPClock:=135;param MaxPClock:=270;field f3M:=PLL2[6..0] offset 2 range 1 to 127;field f3N1:=PLL1[4..0] offset 2 range 1 to 31;field f3N2:=PLL1[6..5] mapped (0=>1,1=>2,2=>4,3=>8);clock f3 is 14318*f3M / f3N1*f3N2;clockmap is (fixed,fixed,NA,f3);for othersparam NoClocks:=16;field ClockSelect:=Control[3..0];end;-Identification procedure.identification begin1: ChipID[7..4] => (0x8=>step 2, 0x9=>S3_928, 0xA=>S3_80x, 0xB=>S3_928,0xC=>S3_864, 0xD=>S3_964, 0xE=>step 3);2: ChipID[1..0] => (0x1=>S3_911,0x2=>S3_924);3: ExtChipID => (0x10=>S3_TRIO32, 0x11=>S3_TRIO64, 0x80=>S3_866,0x90=>S3_868, 0xB0=>S3_968);end;-Register locks on S3 chips.enable access sequence is Lock1<=0x48,Lock2<=0xA5,Slock<=0x6;disable access sequence is Lock1<=0x00,Lock2<=0x5A,Slock<=0x0;
منابع مشابه
A Domain Specific Language for Video Device Drivers: From Design to Implementation
Domain-speci c languages (DSL) have many potential advantages in terms of software engineering ranging from increased productivity to the application of formal methods. Although they have been used in practice for decades, there has been little study of methodology or implementation tools for the DSL approach. In this paper we present our DSL approach and its application to a realistic applicat...
متن کاملDomain-Specific Languages: From Design to Implementation Application to Video Device Drivers Generation
Domain-specific languages (DSL) have many potential advantages in terms of software engineering ranging from increased productivity to the application of formal methods. Although they have been used in practice for decades, there has been little study of methodology or implementation tools for the DSL approach. In this paper we present our DSL approach and its application to a realistic domain:...
متن کاملDomain Speci c Embedded Compilers
Domain-speci c embedded languages (DSELs) expressed in higher-order, typed (HOT) languages provide a composable framework for domain-speci c abstractions. Such a framework is of greater utility than a collection of stand-alone domain-speci c languages. Usually, embedded domain speci c languages are build on top of a set of domain speci c primitive functions that are ultimately implemented using...
متن کاملTowards Verifiable Device Drivers: an Approach Based on Domain-specific Languages Fabrice Mérillon Laurent Réveillère Charles Consel Robin Hansen Renaud Marlet
Although peripheral devices come out at a frantic pace and require fast releases of drivers, little progress has been made to improve the development of drivers. Too often, this development consists of decoding hardware intricacies, based on ambiguous or incomplete documentation , to determine how to operate a device. Then, assembly-level operations need to be used to interact with the device. ...
متن کاملVideo Abstraction in H.264/AVC Compressed Domain
Video abstraction allows searching, browsing and evaluating videos only by accessing the useful contents. Most of the studies are using pixel domain, which requires the decoding process and needs more time and process consuming than compressed domain video abstraction. In this paper, we present a new video abstraction method in H.264/AVC compressed domain, AVAIF. The method is based on the norm...
متن کامل